Vzor Pozorovateľa s JavaScript WeakRef: Budovanie Pamäťovo Vedomých Systémov Udalostí

Vo svete moderného webového vývoja sa jednolistové aplikácie (SPA) stali štandardom pre vytváranie dynamických a responzívnych používateľských skúseností. Tieto aplikácie často bežia dlhú dobu, spravujú komplexný stav a spracovávajú nespočetné množstvo používateľských interakcií. Táto dlhá životnosť však prichádza s ukrytou cenou: zvýšeným rizikom únikov pamäte. Únik pamäte, pri ktorom aplikácia drží pamäť, ktorú už nepotrebuje, môže časom degradovať výkon, čo vedie k pomalosti, pádom prehliadača a zlej používateľskej skúsenosti. Jedným z najčastejších zdrojov týchto únikov je základný návrhový vzor: vzor pozorovateľa.

Vzor pozorovateľa je základom architektúry riadenej udalosťami, ktorá umožňuje objektom (pozorovateľom) prihlasovať sa na odber aktualizácií od centrálneho objektu (predmetu) a prijímať ich. Je elegantný, jednoduchý a nesmierne užitočný. Jeho klasická implementácia má však zásadnú chybu: predmet si udržuje silné referencie na svojich pozorovateľov. Ak pozorovateľ už aplikácia nepotrebuje, ale vývojár zabudne explicitne ho odhlásiť od predmetu, nikdy nebude zozbieraný garbage collectorom. Zostane uväznený v pamäti, duch strašiaci výkon vašej aplikácie.

Tu prichádza na rad moderný JavaScript so svojimi funkciami ECMAScript 2021 (ES12), ktoré ponúkajú silné riešenie. Využitím WeakRef a FinalizationRegistry môžeme vybudovať pamäťovo vedomý vzor pozorovateľa, ktorý sa automaticky postará o úklid a zabráni bežným únikom. Tento článok je hlbokým ponorom do tejto pokročilej techniky. Preskúmame problém, pochopíme nástroje, vybudujeme robustnú implementáciu od základov a prediskutujeme, kedy a kde by sa mal tento výkonný vzor aplikovať vo vašich globálnych aplikáciách.

Porozumenie základnému problému: Klasický vzor pozorovateľa a jeho pamäťová stopa

Predtým, ako dokážeme oceniť riešenie, musíme plne pochopiť problém. Vzor pozorovateľa, známy aj ako vzor vydavateľ-odberateľ (publisher-subscriber), je navrhnutý na de-koreláciu komponentov. Predmet (alebo vydavateľ) si udržuje zoznam svojich závislých objektov, nazývaných pozorovatelia (alebo odberatelia). Keď sa stav predmetu zmení, automaticky upozorní všetkých svojich pozorovateľov, zvyčajne zavolaním špecifickej metódy na nich, ako napríklad update().

Pozrime sa na jednoduchú, klasickú implementáciu v JavaScript.

Jednoduchá implementácia predmetu

Tu je základná trieda Predmet. Má metódy na prihlásenie, odhlásenie a upozornenie pozorovateľov.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} sa prihlásil.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} sa odhlásil.`);

  }

 

  notify(data) {

    console.log('Upozorňujem pozorovateľov...');

    this.observers.forEach(observer => observer.update(data));

  }

}

A tu je jednoduchá trieda Pozorovateľa, ktorá sa môže prihlásiť na odber Predmetu.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} prijal dáta: ${data}`);

  }

}

Skryté nebezpečenstvo: Pretrvávajúce referencie

Táto implementácia funguje perfektne, pokiaľ starostlivo spravujeme životný cyklus našich pozorovateľov. Problém nastáva, keď to nerobíme. Zvážte bežný scenár vo veľkej aplikácii: dlhotrvajúci globálny dátový sklad (predmet) a dočasný komponent používateľského rozhrania (pozorovateľ), ktorý zobrazuje časť týchto údajov.

Simulujme tento scenár:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Komponent vykonáva svoju prácu...

 

  // Teraz používateľ prejde preč a komponent už nie je potrebný.

  // Vývojár mohol zabudnúť pridať kód na úklid:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Uvoľňujeme našu referenciu na komponent.

}

 

manageUIComponent();

 

// Neskôr v životnom cykle aplikácie...

dataStore.notify('Nové dáta sú k dispozícii!');

Vo funkcii `manageUIComponent` vytvoríme `chartComponent` a prihlásime ho na odber nášho `dataStore`. Neskôr nastavíme `chartComponent` na `null`, čo signalizuje, že sme s ním skončili. Očakávame, že garbage collector JavaScriptu (GC) zistí, že už neexistujú žiadne referencie na tento objekt, a uvoľní jeho pamäť.

Ale jedna referencia tam stále existuje! Pole `dataStore.observers` si stále drží priamu, silnú referenciu na objekt `chartComponent`. Kvôli tejto jedinej pretrvávajúcej referencii garbage collector nemôže uvoľniť pamäť. Objekt `chartComponent` a akékoľvek zdroje, ktoré drží, zostanú v pamäti po celú dobu životnosti `dataStore`. Ak sa to stane opakovane — napríklad vždy, keď používateľ otvorí a zatvorí okno s modálnym dialógom — využitie pamäte aplikácie porastie neobmedzene. Toto je klasický únik pamäte.

Nová nádej: Predstavenie WeakRef a FinalizationRegistry

ECMAScript 2021 zaviedol dve nové funkcie špecificky navrhnuté na riešenie týchto typov problémov so správou pamäte: `WeakRef` a `FinalizationRegistry`. Sú to pokročilé nástroje a mali by sa používať opatrne, ale pre náš problém s vzorom pozorovateľa sú dokonalým riešením.

Čo je WeakRef?

Objekt `WeakRef` drží slabú referenciu na iný objekt, nazývaný jeho cieľ. Kľúčový rozdiel medzi slabou referenciou a bežnou (silnou) referenciou je tento: slabá referencia nebráni tomu, aby bol cieľový objekt zozbieraný garbage collectorom.

Ak sú jediné referencie na objekt slabé referencie, JavaScriptový engine môže objekt zničiť a uvoľniť jeho pamäť. Toto je presne to, čo potrebujeme na vyriešenie nášho problému s pozorovateľom.

Na použitie `WeakRef` vytvoríte jeho inštanciu a cieľový objekt odovzdáte do konštruktora. Na neskorší prístup k cieľovému objektu použijete metódu `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// Na prístup k objektu:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Objekt je stále nažive: ${retrievedObject.id}`); // Výstup: Objekt je stále nažive: 42

} else {

  console.log('Objekt bol zozbieraný garbage collectorom.');

}

Kľúčovou časťou je, že `deref()` môže vrátiť `undefined`. Toto sa stane, ak bol `targetObject` zozbieraný garbage collectorom, pretože naň neexistujú žiadne silné referencie. Toto správanie je základom nášho pamäťovo vedomého vzoru pozorovateľa.

Čo je FinalizationRegistry?

Zatiaľ čo `WeakRef` umožňuje zozbierať objekt, neposkytuje nám čistý spôsob, ako vedieť, kedy bol zozbieraný. Mohli by sme periodicky kontrolovať `deref()` a odstraňovať výsledky `undefined` z nášho zoznamu pozorovateľov, ale to je neefektívne. Tu prichádza na rad `FinalizationRegistry`.

`FinalizationRegistry` vám umožňuje zaregistrovať funkciu spätného volania, ktorá bude vyvolaná po tom, čo bol zaregistrovaný objekt zozbieraný garbage collectorom. Je to mechanizmus na úklid po zániku.

Funguje to takto:

1. Vytvoríte register s funkciou spätného volania na úklid.
2. Zaregistrujete (`register()`) objekt do registra. Môžete tiež poskytnúť `heldValue`, čo je kus dát, ktorý bude odovzdaný vašej funkcii spätného volania, keď bude objekt zozbieraný. Toto `heldValue` nesmie byť priamou referenciou na samotný objekt, pretože by to zmarilo účel!

// 1. Vytvorenie registra s funkciou spätného volania na úklid

const registry = new FinalizationRegistry(heldValue => {

  console.log(`Objekt bol zozbieraný garbage collectorom. Token úklidu: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Dočasné dáta' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Registrácia objektu a poskytnutie tokenu pre úklid

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack tu končí svoj rozsah

})();

 

// V nejakom bode v budúcnosti, po spustení GC, konzola vypíše:

// "Objekt bol zozbieraný garbage collectorom. Token úklidu: temp-data-123"

Dôležité poznámky a najlepšie postupy

Predtým, ako sa pustíme do implementácie, je kritické pochopiť povahu týchto nástrojov. Správanie garbage collectora je silne závislé od implementácie a nedeterministické. To znamená:

• Nemôžete predvídať, kedy bude objekt zozbieraný. Môže to byť sekundy, minúty alebo dokonca dlhšie po tom, čo sa stal nedostupným.
• Nemôžete sa spoľahnúť na to, že spätné volania `FinalizationRegistry` sa spustia včas alebo predvídateľne. Sú určené na úklid, nie na kritickú logiku aplikácie.
• Nadmerné používanie `WeakRef` a `FinalizationRegistry` môže spôsobiť, že kód bude ťažšie pochopiteľný. Vždy uprednostnite jednoduchšie riešenia (ako explicitné volania `unsubscribe`), ak sú životné cykly objektov jasné a zvládnuteľné.

Tieto funkcie sú najvhodnejšie pre situácie, kde je životný cyklus jedného objektu (pozorovateľa) skutočne nezávislý a neznámy druhému objektu (predmetu).

Budovanie vzoru `WeakRefObserver`: Implementácia krok za krokom

Teraz skombinujeme `WeakRef` a `FinalizationRegistry` na vybudovanie bezpečnej triedy `WeakRefSubject` voči pamäti.

Krok 1: Štruktúra triedy `WeakRefSubject`

Naša nová trieda bude ukladať `WeakRef` na pozorovateľov namiesto priamych referencií. Bude tiež obsahovať `FinalizationRegistry` na spracovanie automatického úklidu zoznamu pozorovateľov.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Používa sa Set pre ľahšie odstránenie

 

    // Spätné volanie finalizátora. Prijíma hodnotu, ktorú sme poskytli pri registrácii.

    // V našom prípade bude hodnotaou inštancia WeakRef samotná.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizátor: Pozorovateľ bol zozbieraný garbage collectorom. Prebieha úklid...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Používame `Set` namiesto `Array` pre náš zoznam pozorovateľov. Je to preto, že odstránenie prvku z `Set` je oveľa efektívnejšie (priemerná časová zložitosť O(1)) ako filtrovanie `Array` (O(n)), čo bude užitočné v našej logike úklidu.

Krok 2: Metóda `subscribe`

Metóda `subscribe` je miestom, kde začína kúzlo. Keď sa pozorovateľ prihlási na odber, budeme:

1. Vytvoríme `WeakRef`, ktorý ukazuje na pozorovateľa.
2. Tento `WeakRef` pridáme do nášho `Set` `observers`.
3. Zaregistrujeme pôvodný objekt pozorovateľa do nášho `FinalizationRegistry`, pričom ako `heldValue` použijeme novo vytvorený `WeakRef`.

// Vo vnútri triedy WeakRefSubject...

subscribe(observer) {

  // Skontrolujte, či už pozorovateľ s touto referenciou existuje

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Pozorovateľ je už prihlásený.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Registrácia pôvodného objektu pozorovateľa. Keď bude zozbieraný,

  // spätné volanie finalizátora bude vyvolané s `weakRefObserver` ako argumentom.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('Pozorovateľ sa prihlásil na odber.');

}

Toto nastavenie vytvára prefíkanú slučku: predmet drží slabú referenciu na pozorovateľa. Register drží silnú referenciu na pozorovateľa (internne), kým nebude zozbieraný garbage collectorom. Po zozbieraní sa spustí spätné volanie registra, ktoré môžeme použiť na úklid nášho zoznamu `observers`.

Krok 3: Metóda `unsubscribe`

Dokonca aj s automatickým úklidom by sme mali stále poskytnúť manuálnu metódu `unsubscribe` pre prípady, keď je potrebný deterministický odstránenie. Táto metóda bude musieť nájsť správny `WeakRef` v našom `Set` dereferencovaním každého z nich a porovnaním s pozorovateľom, ktorého chceme odstrániť.

// Vo vnútri triedy WeakRefSubject...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // DÔLEŽITÉ: Musíme tiež odhlásiť od finalizátora

    // aby sme zabránili zbytočnému spusteniu spätného volania neskôr.

    this.cleanupRegistry.unregister(observer);

    console.log('Pozorovateľ sa manuálne odhlásil.');

  }

}

Krok 4: Metóda `notify`

Metóda `notify` iteruje cez náš zoznam `WeakRef`ov. Pre každý z nich sa pokúsi zavolať `deref()` na získanie skutočného objektu pozorovateľa. Ak `deref()` uspeje, znamená to, že pozorovateľ je stále nažive a môžeme zavolať jeho metódu `update`. Ak vráti `undefined`, pozorovateľ bol zozbieraný a my ho môžeme jednoducho ignorovať. `FinalizationRegistry` nakoniec odstráni jeho `WeakRef` zo zoznamu.

// Vo vnútri triedy WeakRefSubject...

notify(data) {

  console.log('Upozorňujem pozorovateľov...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Pozorovateľ je stále nažive

      observer.update(data);

    } else {

      // Pozorovateľ bol zozbieraný garbage collectorom.

      // FinalizationRegistry sa postará o odstránenie tohto weakRef zo zoznamu.

      console.log('Počas upozorňovania nájdená mŕtva referencí pozorovateľa.');

    }

  }

}

Dáme to dokopy: Praktický príklad

Vráťme sa k nášmu scenáru s komponentom používateľského rozhrania, ale tentoraz použijeme náš nový `WeakRefSubject`. Pre jednoduchosť použijeme rovnakú triedu `Observer` ako predtým.

// Rovnaká jednoduchá trieda Observer

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} prijal dáta: ${data}`);

  }

}

Teraz vytvoríme globálnu dátovú službu a simulujeme dočasný widget používateľského rozhrania.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Vytváram a prihlasujem nový widget ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // Widget je teraz aktívny a bude prijímať upozornenia

  globalDataService.notify({ price: 100 });

 

  console.log('--- Ničím widget (uvoľňujem našu referenciu) ---');

  // S widgetom sme skončili. Nastavíme našu referenciu na null.

  // NEMUSÍME volať unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- Po zničení widgetu, pred zberom odpadu ---');

globalDataService.notify({ price: 105 });

Po spustení `createAndDestroyWidget()` je objekt `chartWidget` teraz odkazovaný iba `WeakRef`om v našej `globalDataService`. Pretože je to slabá referencia, objekt je teraz pripravený na zozbieranie garbage collectorom.

Keď sa garbage collector nakoniec spustí (čo nemôžeme predvídať), stanú sa dve veci:

1. Objekt `chartWidget` bude odstránený z pamäte.
2. Bude vyvolaná spätná volanie nášho `FinalizationRegistry`, ktorá následne odstráni už neaktívny `WeakRef` zo zoznamu `globalDataService.observers`.

Ak potom znova zavoláme `notify` po tom, čo sa spustil garbage collector, volanie `deref()` vráti `undefined`, mŕtvy pozorovateľ bude preskočený a aplikácia bude naďalej bežať efektívne bez akýchkoľvek únikov pamäte. Úspešne sme oddelili životný cyklus pozorovateľa od predmetu.

Kedy použiť (a kedy sa vyhnúť) vzoru `WeakRefObserver`

Tento vzor je výkonný, ale nie je to strieborná guľka. Zavádza komplexnosť a spolieha sa na nedeterministické správanie. Je nevyhnutné vedieť, kedy je to správny nástroj pre danú úlohu.

Ideálne prípady použitia

• Predmety s dlhou životnosťou a pozorovatelia s krátkou životnosťou: Toto je kánonický prípad použitia. Globálna služba, dátový sklad alebo cache (predmet), ktorý existuje po celý životný cyklus aplikácie, zatiaľ čo početné komponenty používateľského rozhrania, dočasní pracovníci alebo doplnky (pozorovatelia) sa vytvárajú a ničia často.
• Mechanizmy cache: Predstavte si cache, ktorá mapuje komplexný objekt na nejaký vypočítaný výsledok. Pre kľúčový objekt môžete použiť `WeakRef`. Ak je pôvodný objekt zozbieraný garbage collectorom z zvyšku aplikácie, `FinalizationRegistry` môže automaticky vyčistiť zodpovedajúcu položku vo vašej cache, čím sa zabráni rastu pamäte.
• Architektúry pluginov a rozšírení: Ak budujete základný systém, ktorý umožňuje modulom tretích strán prihlasovať sa na odber udalostí, použitie `WeakRefObserver` pridáva vrstvu odolnosti. Zabraňuje tomu, aby zle napísaný plugin, ktorý zabudne odhlásiť sa, spôsobil únik pamäte vo vašej základnej aplikácii.
• Mapovanie údajov na DOM prvky: V scenároch bez deklaratívneho rámca môžete chcieť asociovať údaje s DOM prvkom. Ak ich uložíte do mapy s DOM prvkom ako kľúčom, môžete vytvoriť únik pamäte, ak je prvok odstránený z DOM, ale stále je vo vašej mape. `WeakMap` je tu lepšou voľbou, ale princíp je rovnaký: životný cyklus údajov by mal byť viazaný na životný cyklus prvku, nie naopak.

Kedy zostať pri klasickom pozorovateľovi

• Tesne spojené životné cykly: Ak sú predmet a jeho pozorovatelia vždy vytváraní a ničení spoločne alebo v rámci rovnakého rozsahu, réžia a zložitosť `WeakRef` sú zbytočné. Jednoduché, explicitné volanie `unsubscribe()` je čitateľnejšie a predvídateľnejšie.
• Výkonnostne kritické cesty: Metóda `deref()` má malú, ale nenulovú výkonnostnú réžiu. Ak upozorňujete tisíce pozorovateľov stokrát za sekundu (napr. v hernej slučke alebo vizualizácii údajov s vysokou frekvenciou), klasická implementácia s priamymi referenciami bude rýchlejšia.
• Jednoduché aplikácie a skripty: Pre menšie aplikácie alebo skripty, kde je životnosť aplikácie krátka a správa pamäte nie je významným problémom, je klasický vzor jednoduchší na implementáciu a pochopenie. Nepridávajte zložitosť tam, kde nie je potrebná.
• Keď je potrebný deterministický úklid: Ak potrebujete vykonať akciu presne v momente, keď je pozorovateľ odpojený (napr. aktualizácia čítača, uvoľnenie špecifického hardvérového zdroja), musíte použiť manuálnu metódu `unsubscribe()`. Nedeterministická povaha `FinalizationRegistry` ho robí nevhodným pre logiku, ktorá musí bežať predvídateľne.

Širšie dôsledky pre softvérovú architektúru

Zavedenie slabých referencií do vysokoúrovňového jazyka, ako je JavaScript, signalizuje dozrievanie platformy. Umožňuje vývojárom budovať sofistikovanejšie a odolnejšie systémy, najmä pre dlhotrvajúce aplikácie. Tento vzor podporuje zmenu v architektonickom myslení:

• Skutočné oddelenie: Umožňuje úroveň oddelenia, ktorá presahuje len rozhranie. Teraz môžeme oddeliť samotné životné cykly komponentov. Predmet už nemusí vedieť nič o tom, kedy sú jeho pozorovatelia vytvorení alebo zničení.
• Odolnosť navrhnutá: Pomáha budovať systémy, ktoré sú odolnejšie voči chybám programátorov. Zabudnuté volanie `unsubscribe()` je bežná chyba, ktorú je ťažké odhaliť. Tento vzor zmierňuje celú túto triedu chýb.
• Umožnenie autorom rámcov a knižníc: Pre tých, ktorí budujú rámce, knižnice alebo platformy pre iných vývojárov, sú tieto nástroje neoceniteľné. Umožňujú vytvárať robustné API, ktoré sú menej náchylné na nesprávne použitie používateľmi knižnice, čo vedie k celkovo stabilnejším aplikáciám.

Záver: Výkonný nástroj pre moderného JavaScript vývojára

Klasický vzor pozorovateľa je základným stavebným kameňom softvérového dizajnu, ale jeho závislosť od silných referencií bola dlho zdrojom jemných a frustrujúcich únikov pamäte v aplikáciách JavaScript. S príchodom `WeakRef` a `FinalizationRegistry` v ES2021 teraz máme nástroje na prekonanie tohto obmedzenia.

Prešli sme od pochopenia základného problému pretrvávajúcich referencií k vybudovaniu kompletnej, pamäťovo vedomého `WeakRefSubject` od základov. Videli sme, ako `WeakRef` umožňuje garbage collectoru zbierať objekty, aj keď sú „pozorované“, a ako `FinalizationRegistry` poskytuje automatizovaný mechanizmus úklidu na udržanie nášho zoznamu pozorovateľov v bezchybnom stave.

Avšak s veľkou mocou prichádza veľká zodpovednosť. Toto sú pokročilé funkcie, ktorých nedeterministická povaha si vyžaduje starostlivé zváženie. Nie sú náhradou za dobrý návrh aplikácie a dôslednú správu životného cyklu. Ale keď sa aplikujú na správne problémy — ako je napríklad komunikácia medzi dlhotrvajúcimi službami a efemérnymi komponentmi — vzor WeakRef Observer je výnimočne výkonná technika. Tým, že si ju osvojíte, môžete písať robustnejšie, efektívnejšie a škálovateľnejšie JavaScript aplikácie, pripravené splniť požiadavky moderného, dynamického webu.